This invention relates to the field of workflow process management and more particularly to a system and method for performing scalable distribution of process flow activities in a distributed workflow management system.
Workflow process re-engineering, that is, the fundamental rethinking and re-implementation of workflow processes to achieve never-before-possible levels of quality, cost, throughput and service, is emerging as one of the crucial business strategies of the 1990s. The need for re-engineering is especially significant in an era of workforce downsizing coupled with greater demands for shortened time to market and faster customer response. Moreover, the need is pervasive. Organizations are currently engaging in workflow process re-engineering in many domains, including financial services, telecommunications services, healthcare services, customer order fulfillment, manufacturing procedure automation and electronic commerce.
While workflow process re-engineering provides a business management concept, workflow process management (WFPM) software--or more accurately, middleware--provides the enabling technologies for actually performing workflow process re-engineering. WFPM supports flexible solutions for the management of enterprise-wide operations, including workflow process control, automation and monitoring; resource allocation, authorization and authentication; task initialization and data exchange; and end-to-end communication and security. However, while WFPM offers an overall environment and approach to unifying, automating and measuring workflow processes, it is not limited to supporting workflow process re-engineering and can be used to manage existing nonautomated legacy or work processes.
In general, WFPM systems perform a wide range of tasks. For instance, they can provide a method for defining and managing the flow of a work process or support the definition of resources and their attributes. In addition, they can assign resources to work, determine which steps will be executed next within a work process and when they will be executed and can ensure that the workflow process continues until proper termination. Moreover, they can notify resources about pending work, enforce administrative policies, such as access control and track execution and support user inquiries of status. Finally, they can provide history information in the form of an audit trail for completed workflow processes and collect statistical data for process and resource bottleneck analysis, flow optimization and automatic workload balancing.
Moreover, given the trend towards open systems and standards, a WFPM system must coexist with and take advantage of standards-based commercial products for network communication, legacy application invocation and system monitoring. In particular, these standards include the Object Management Group's Common Object Request Broker Architecture (CORBA), the Open Software Foundation's Distributed Computing Environment (OSF DCE), Hewlett Packard's OpenView and the International Standards Organization Open Systems Interconnection (ISO OSI) X.400 technologies.
In general, WFPM systems, or simply, process flow systems, effect workflow processes on a small- to large-scale basis by controlling the scheduling of and parameters used by activities, acquiring the results of the activities and using those results to determine other activities to run. Each individual business process describes the sequencing, timing, dependency, data, physical agent allocation, business rule and organization policy enforcement requirements for performing work.
Prior art process flow systems have been disclosed. However, those disclosed prior art process flow systems cannot be readily applied to large-scale applications for two reasons.
First, application-specific data, further described below in the Detailed Description, is improperly treated as process-relevant data. End activities are required to perform all data accesses directly upon the database storing the application-specific data. However, when the application-specific data is copied into the process-relevant data, the data may be independently modified by the process flow system. Such updates often damage the intended transactional semantics of the application database. Moreover, the amount of information that the process flow engine must log, process and dispatch increases.
Second, users must review and select from lists of available work by communicating directly with the process flow system. This direct interface adds work to the system that could be done by separate processes on independent resources and limits the system's size. Also, since the process flow system must deal directly with client worklist requests, potential performance is lost in dealing with user requests to see what work is available. Moreover, such user requests are often non-randomly distributed and the system must have sufficient computing capacity available to deal with these bursty requests.
Therefore, there is a need for a system and method for providing high degree of scalability to process flow systems. Preferably, such a system and method would provide an enterprise-wide process flow solution.
There is a further need for a system and method for managing a process flow system providing a bidirectional proxies for processing user work requests, handling application-specific data and effecting transport interfacing.